A native Quack attach (quack:HOST:PORT) against an unresponsive endpoint
hangs indefinitely — observed in practice when the target is reachable at
the TCP level but never completes the protocol handshake (for example a
plain-HTTP listener on a non-loopback address, which the extension contacts
over TLS). Because the hang is inside the DuckDB extension, every command
that attaches a remote mirror (duckdb push, duckdb status,
duckdb serve with a remote URL) blocks forever with no error.

This makes the remote attach path fail fast instead:

• A TCP preflight (net.DialTimeout) against the host:port extracted from
  the quack URL catches unreachable or blackholed endpoints before the
  extension is even loaded. The address extraction handles the native
  quack:host:port form, IPv6 brackets, userinfo, and URL-scheme forms
  with default ports.
• A watchdog around the ATTACH itself runs the statement in a goroutine and
  selects on completion versus a timer, returning an error that names the
  endpoint and the timeout knob. This covers the observed repro shape:
  TCP connects, then the handshake stalls.

The timeout is configurable as [duckdb].attach_timeout /
AGENTSVIEW_DUCKDB_ATTACH_TIMEOUT, defaulting to 20s. A negative value
disables the guard; zero means "use the default" because a TOML duration
zero-value is indistinguishable from unset.

Tradeoffs: a timed-out ATTACH may leak its goroutine and connection, since
the extension call cannot be interrupted from Go — accepted and documented
in a code comment, as callers treat a failed attach as fatal. Scope is the
initial attach only; the existing stale-connection reattach retry path
during a live session is unchanged. Local file opens are untouched.

Where to look: internal/duckdb/connect.go (preflightQuackDial,
runWithAttachTimeout, openQuackClient), the knob registration in
internal/config/config.go, and docs/duckdb.md for the documentation.